Компания StarWind, ведущий производитель решений для создания отказоустойчивых программных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, приглашает на бесплатный вебинар "Building a stretched cluster: Keep your data always secure". Таги:
Больше пяти лет назад мы писали про проект vCenter Server Simulator 2.0 (VCSIM), который позволял протестировать основные интерфейсы VMware vCenter без необходимости его реального развертывания (а значит и без лицензии). Проблема в том, что он был выпущен для VMware vSphere и vCenter версий 5.5 и с тех пор не обновлялся.
Зато есть аналог старому VCSIM - новый проект govcsim, написанный на языке Go (Golang). Он точно так же умеет предоставлять API-ответы на вызовы к vCenter Server и ESXi.
Несмотря на то, что этот симулятор написан на Go, он позволяет вам работать с vCenter посредством любого языка и интерфейса, умеющего общаться через API (в том числе, PowerShell). То есть, вы можете соединиться через PowerCLI к VCSIM Docker Container и работать с ним как с сервером vCenter.
Сам контейнер nimmis/vcsim можно скачать отсюда. Pull-команда для него:
If ($PSVersionTable.PSVersion.Major -ge 6) {
Test-Connection $Server -TCPPort 443
}
Connect-VIServer -Server $Server -Port 443 -User u -Password p
# Did it work?
Get-VM
# Or Get-VMHost, or Get-Datastore, etc.
Этот код делает следующее:
Запускает docker-контейнер VCSIM локально (если у вас его нет, то он будет загружен).
На Windows-системе получает IP-адрес адаптера DockerNAT.
После запуска контейнера тестирует, что порт 443 отвечает.
Использует модуль VMware.PowerCLI интерфейса PowerShell для соединения с vCenter Simulator.
Симулятор на данный момент поддерживает не все множество API-методов (смотрите документацию). Вот так, например, можно вывести список всех поддерживаемых методов и типов:
$About = Invoke-RestMethod -Uri "https://$($Server):443/about" -Method Get
$About.Methods
$About.Types
Например, вы можете использовать PowerOffVM_Task, PowerOnMultiVM_Task и PowerOnVM_Task. Из PowerCLI попробуйте также протестировать командлеты Stop-VM и Start-VM. Ну а дальше изучайте документацию к библиотеке govmomi.
Во время прошедшего летом прошлого года VMworld 2018 компания VMware представила много интересных новостей на тему будущей функциональности продукта для создания отказоустойчивых хранилищ VMware vSAN. Например, мы писали о технологии Native Data Protection (это часть 1 этого цикла статей), а сегодня поговорим о сервисах хранения.
Диски First Class Disk (FCD)
Для vSAN уже есть поддержка так называемых дисков First Class Disk (FCD), они же называются Improved Virtual Disk (IVDs) или Managed Virtual Disk. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования.
К таким относятся, например, тома VMware App Volumes, на которых размещаются приложения, и которые присоединяются к виртуальным машинам во время работы пользователя с основной машиной. Также к таким дискам относятся хранилища для cloud native приложений и приложений в контейнерах, например, работающих через Docker Plugin и драйвер Kubernetes (он называется vSphere Cloud Provider) для создания постоянных (persistent) томов контейнеров Docker. Этим всем занимается опенсорсный проект Project Hatchway от VMware.
Работать с такими дисками очень неудобно - для них приходится создавать отдельную виртуальную машину к которой цепляется этот диск, а потом, по завершении какого-либо процесса, отсоединяется, и машина уничтожается. Так, например, работает средство для резервного копирования App Volumes Backup Utility, о котором мы писали вот тут. При бэкапе этих дисков создается временная Backup VM:
Второй пример - инфраструктура vSphere Integrated OpenStack (VIO), где для того, чтобы включить хранилище Cinder (OpenStack Block Storage) для потребления дисковой емкости VMDK-файлов, нужно создавать вспомогательные Shadow VM для каждого тома Cinder, к которому цепляется VMDK-диск.
Все это неудобно, поэтому и придумали формат дисков First Class Disk (FCD), которому не требуются временные виртуальные машины и которые реализуют сервисы, необходимые приложениям или другим сервисам. Например, бэкап таких дисков можно делать без создания вспомогательной ВМ.
Информация о дисках FCD хранится в каталоге базы данных vCenter. Она содержит глобальные уникальные идентификаторы UUID и имена дисков. UUID позволяет переместить диск в любое место без конфликтов.
В vSphere 6.7 это ограничение было снято, но остались еще некоторые требования - FCD нужно было восстанавливать с тем же UUID и на тот же датастор, откуда он был взят. Также еще одним ограничением была невозможность API отслеживать блоки, изменившиеся с момента последней резервной копии, то есть невозможность инкрементального резервного копирования (подробнее здесь).
Ну а в vSphere 6.7 Update 1 была анонсирована ограниченная поддержка FCD для vSAN. Пока поддержка предоставляется еще с ограничениями для служб health service и capacity monitoring. Однако при этом пользователи Kubernetes могут использовать диски FCD на хранилищах vSAN для персистентных хранилищ контейнеров, и в то же самое время тома vSAN могут использоваться для виртуальных машин:
Подписаться на бету следующей версии продукта VMware vSAN можно по этой ссылке.
В следующей статье мы расскажем про Cloud Native Storage (CNS) и vSAN File Services.
Вебинар пройдет 7 февраля в 22-00 по московскому времени.
На мероприятии Алексей расскажет обо всех нюансах развертывания географически "растянутого" кластера для виртуальных машин в части хранилищ. В рамках вебинара будет рассказано, как построить такой кластер, каким аспектам отказоустойчивости (HA) уделить особое внимание, и какие меры необходимо принять в целях обеспечения безопасности такой среды. Ну и, конечно же, Алексей расскажет о том, как предотвратить ситуацию Split Brain в таких сценариях.
Недавно компания VMware объявила о выпуске обновленной версии решения VMware PKS 1.3 (Pivotal Container Service), предназначенного для управления гибридными средами Kubernetes в онпремизных и публичных облаках. Напомним, что об анонсах на VMworld Europe 2018, касающихся этого продукта, мы писали вот тут.
Тогда было объявлено о покупке компании Heptio, которую основали создатели Kubernetes. Она предоставляет набор продуктов и профессиональных сервисов для управления контейнерами Kubernetes в онпремизных, публичных и гибридных облачных средах. Помимо управления контейнерами, решения Heptio предоставляют такие сервисы, как оркестрация приложений, поддержка жизненного цикла (развертывание, хэлсчек) и обеспечение доступности (снапшоты, резервное копирование).
Теперь кое-что из этого было добавлено в VMware PKS, который стал поддерживать облачную среду Microsoft Azure. Кроме того, в продукте были улучшены функции контроля сетевого взаимодействия, безопасности и управления.
Давайте посмотрим, что нового появилось в PKS 1.3:
1. Поддержка публичного облака Microsoft Azure.
Ранее PKS поддерживал облачные среды VMware vSphere, Google Cloud Platform и Amazon EC2. Теперь он работает и в Azure:
PKS позволяет самостоятельно развернуть кластеры Kubernetes в облаке (или сразу нескольких облаках) и получить все инструменты для ежедневной эксплуатации решения.
2. Улучшения гибкости и средств настройки сетевой среды и инфраструктуры безопасности.
Теперь сетевые профили кластеров, которые появились еще в версии 1.2, получили еще больше параметров настройки.
Поддержка нескольких Tier 0 маршрутизаторов для лучшей изоляции контейнерных сред. Один экземпляр VMware NSX-T может обслуживать несколько Tier 0 маршрутизаторов, что дает не только функции безопасности, но и возможности настройки отдельных диапазонов IP для каждого роутера и его клиентов.
Маршрутизируемые IP-адреса, назначаемые группам узлов (Pods), что позволяет обеспечить их прозрачную коммуникацию с внешним миром (а также достучаться к ним из внешнего мира). Если необходимо, можно использовать и NAT-схему. Более подробно об этом написано здесь.
Для групп Pods можно перекрыть глобальные настройки диапазона IP-адресов и размера подсети, задав их для отдельных групп. Это дает больше гибкости в плане использования глобального диапазона адресов.
Поддержка больших (large) балансировщиков в дополнение к small и medium. Это увеличивает число предоставляемых сервисов, число групп на бэкенде в расчете на сервис, а также количество транзакций в секунду на сервис.
Лучшая изоляция окружений за счет размещения нескольких VMware PKS Control Planes в рамках одного экземпляра NSX-T. Каждый управляющий объект VMware PKS control plane можно разместить на выделенном маршрутизаторе NSX-T Tier 0. Это позволяет лучше разделить окружения и, например, обновлять тестовую среду независимо от производственной, работая с двумя экземплярами PKS.
3. Улучшенные операции управления.
Здесь произошли следующие улучшения:
Средства резервного копирования и восстановления кластеров Kubernetes. Теперь, помимо бэкапа средств управления Control Planes, появилась возможность бэкапа и stateless-нагрузок в контейнерах средствами тулсета BOSH Backup and Restore (BBR).
Возможность проведения смоук-тестов. С помощью PKS 1.3 возможно создание специализированной тестовой среды, которую можно использовать для проверки апгрейда кластера, чтобы убедиться, что на производственной среде апгрейд пройдет нормально. После окончания теста тестовый кластер удаляется, после чего можно спокойно апгрейдить продакшен.
4. Поддержка Kubernetes 1.12 и другие возможности.
VMware PKS 1.3 поддерживает все стабильные физи релиза Kubernetes 1.12. Со стороны VMware они прошли тесты Cloud Native Computing Foundation (CNCF) Kubernetes conformance tests.
Также в рамках одной группы контейнеры могут иметь общие тома. Это может пригодиться, например, для общей базы данных нескольких приложений в разных контейнерах.
Кроме того, компоненты NSX-T и другие управляющие элементы, такие как VMware vCenter, можно разместить за HTTP proxy, требующим аутентификации. Ну и VMware PKS 1.3 включает решение Harbor 1.7 с новыми возможностями, такими как управление диаграммами Helm, улучшенная поддержка LDAP, репликация образов и миграции базы данных.
Более подробно о VMware PKS 1.3 написано по этой ссылке. Также больше подробностей об обновлении можно узнать тут, а вот тут можно пройти практическую лабораторную работу по решению PKS.
Компания StarWind Software, известная своим лидирующим решением Virtual SAN для создания отказоустойчивых хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V, продолжает выпускать полезные бесплатные утилиты. Например, напомним, что ранее мы писали о StarWind Deduplication Analyzer.
На этот раз StarWind выпустила средства для бенчмаркинга RDMA-соединений между серверными системами, которые используются для прямого доступа к памяти между хостами в рамках кластера.
Для тестирования RDMA-соединений есть различные утилиты, но они разработаны для различных операционных систем, и их трудно сопрягать между собой. Также они показывают либо задержки (latency), либо пропускную способность (bandwidth), а rPerf выводит обе этих метрики. Ну и, конечно же, ее можно использовать для Windows и Linux одновременно.
Давайте посмотрим, как это работает. Для тестирования вам понадобятся системы Windows 7 / Windows Server 2012 или более поздние, а если вы хотите использовать Linux - то CentOS 7 или
Ubuntu.
Сетевой адаптер (NIC) должен иметь настроенные механизмы Network Direct Provider v1 и lossless RDMA. Для адаптеров нужны последние версии драйверов, так как стандартный драйвер Windows не поддерживает ND API. Для систем Linux нужны драйвера с поддержкой RDMA и RoCE.
Чтобы централизованно обновлять VMware для всех ВМ, вам нужно настроить единый репозиторий на всех хостах ESXi, из которого будет происходить апдейт. Сначала нужно создать для этого папку, например:
/vmfs/volumes/vsanDatastore/vmtools
Далее нужно скачать последнюю версию VMware Tools по ссылке выше и положить ее в созданную папку (включая папки "vmtools" и "floppies").
Теперь на каждом хосте ESXi нужно обновить указатель ProductLocker через интерфейс MOB (Managed Object Browser). Для этого надо зайти по ссылке:
Далее нужно выбрать хост ESXi, для которого вы хотите обновить этот указатель. Здесь есть два API вызова, которые вам понадобятся:
Вызов QueryProductLockerLocation покажет вам текущий указатель на папку с VMware Tools на хосте (ProductLocker):
Метод UpdateProductLockerLocation_Task позволит вам обновить размещение для пакетов VMware Tools для этого хоста, добавив путь к нужной папке в параметр path:
Теперь снова вызовите QueryProductLockerLocation, чтобы увидеть, что путь к папке обновился:
Теперь все остальные хосты ESXi также нужно перенастроить на путь к этой папке, чтобы они брали обновления VMware Tools из единого места, где всегда будет лежать последняя версия пакета.
Квоты хранилищ позволяют администратору vSphere задавать лимиты хранения, которые доступны объектам Docker Endpoint, с помощью опции --storage-quota для команды vic-machine create. Квоты можно задавать для каждого из объектов Virtual Container Host (VCH), они срабатывают при создании контейнера или загрузке образа. В примере ниже видно, что квота задана на уровне 15 ГБ и при попытке завести еще один контейнер busybox возникает ошибка о превышении квоты по хранилищу.
2. Возможность загрузки альтернативного ядра Linux Kernel.
Photon OS дает массу возможностей для загрузки контейнеров, однако некоторым пользователям требуется собственная конфигурация ядра или вообще другой Linux-дистрибутив. Для них сделана возможность загружать собственное ядро, например, ниже приведена команда для запуска ядра CentOS 6.9, в среде которого будут работать контейнеры:
Помимо поддержки решения VMware NSX-V, которая была введена в прошлых версиях, теперь VIC 1.5 поддерживает и решение NSX-T для обеспечения прозрачной коммуникации между контейнерами, с управлением на основе политик и микросегментацией трафика. Делается это с помощью команды vic-machine create –container-network.
Виртуальные машины с контейнерами могут быть подключены к распределенной портгруппе логического коммутатора NSX, что позволяет использовать выделенное соединение этих ВМ к сети:
4. Поддержка Photon OS.
vSphere Integrated Containers 1.5 поставляется со всеми необходимыми компонентами для работы с Photon OS версии 2.0. Этот релиз предоставляет расширенные возможности обеспечения безопасности, а также поддерживает все новые функции второй версии Photon OS.
Получить больше информации о VIC 1.5 можно на этой странице.
На сайте проекта VMware Labs появился апдейт основного средства управления виртуальной инфраструктурой - VMware vSphere Client 4.0. Напомним, что, начиная с версии vSphere 6.7 Update 1, vSphere Client является официально поддерживаемым средством управления для всех рабочих процессов платформы vSphere. О последней версии vSphere Client 3.42 мы писали осенью прошлого года вот тут.
Теперь VMware в обновленной версии клиента исправила несколько ошибок, а также отключила поддержку старых версий VMware vSphere. Новый клиент работает, начиная с vSphere 6.5 и более поздними версиями. То есть, если у вас vSphere 6.0, то не обновляйте ваш клиент (тем более, что линка на загрузку прошлой версии уже нет), а используйте версию 3.42, которая реализует весь функционал.
Также надо помнить, что если вы используете vSphere 6.5, то у вас будет недоступен плагин к VMware vSphere Update Manager (VUM). Интересно, что в Changelog написано о том, что в клиенте есть некоторые New Features, но не написано, какие именно)
UPD. Новый клиент vSphere Client 4.0 предоставляет следующие новые возможности:
Поддержка VMware vCenter 6.7, браузер просмотра файлов и папок стал работать заметно быстрее.
Графический интерфейс ESX Agent Manager.
Настройки MxN Convergence в разделе System Configuration
Возможность импорта сертификатов и генерации запроса CSR.
Функции Code Capture: кнопка записи может быть нажата между состояниями hidden и shown.
Возможность удалить бандлы скриптов (Script Bundles) в механизме Autodeploy для vCenter 6.7.
Возможность удалить Discovered hosts в механизме Autodeploy для vCenter 6.7.
Экспорт данных о лицензиях в формате CSV для всех представлений, связанных с просмотром лицензий.
Добавление и назначение лицензий в рамках одной операции.
Настройка аутентификации на прокси-сервере для VC 6.5+ (раздел VC > Configure > Settings > Authentication Proxy).
При обновлении клиента на версию vSphere Client 4.0 с 3.x вам нужно будет повторно подключить его к инфраструктуре vSphere и ввести учетные данные.
Скачать VMware vSphere Client 4.0 можно по этой ссылке.
В прошлом посте мы рассказывали о IOchain - цепочке прохождения пакетов через сетевой стек хоста VMware ESXi, а в этом остановимся на некоторых утилитах, работающих с этим стеком и помогающих решать различного рода сетевые проблемы.
Прежде всего, при решении проблем соединений на хосте ESXi нужно использовать следующие средства:
Но если хочется углубиться дальше в сетевое взаимодействие на хосте, то тут могут оказаться полезными следующие утилиты:
net-stats
pktcap-uw
nc
iperf
1. Net-stats.
Чтобы вывести весь список флагов этой команды, используйте net-stats -h, а вот для вывода детальной информации о номерах портов и MAC-адресах всех интерфейсов используйте команду:
net-stats -l
С помощью net-stats можно делать огромное количество всяких вещей, например, проверить включены ли на интерфейсе vmnic функции NetQueue или Receive Side Scaling (RSS) с помощью команды:
net-stats -A -t vW
Далее нужно сопоставить вывод блока sys для нужного интерфейса и вывода команды:
vsish -e cat /world/<world id>/name
2. Pktcap-uw.
Эта утилита совместно с tcpdump-uw захватывать пакеты на различных уровнях. Если tcpdump-uw позволяет захватывать пакеты только с интерфейсов VMkernel, то pktcap-uw умеет захватывать фреймы на уровне виртуального порта, коммутатора vSwitch или аплинка.
В KB 2051814 подробно описано, как можно использовать утилиту pktcap-uw. На картинке ниже представлен синтаксис использования команды, в зависимости от того, на каком уровне мы хотим ее применить:
Фильтрация пакетов для выбранного MAC-адреса:
pktcap-uw --mac xx:xx:xx:xx:xx:xx
Фильтрация пакетов для выбранного IP-адреса:
pktcap-uw --ip x.x.x.x
Автоматическое исполнение и завершение pktcap-uw с использованием параметра sleep:
pktcap-uw $sleep 120; pkill pktcap-uw
Ограничить захват заданным числом пакетов:
pktcap-uw -c 100
Перенаправить вывод в файл:
pktcap-uw -P -o /tmp/example.pcap
3. NC
NC - это олдскульная Linux-команда NetCat. Она позволяет проверить соединение по указанному порту, так как telnet недоступен на ESXi. Например, так можно проверить, что можно достучаться через интерфейс iSCSI по порту 3260 до системы хранения:
nc -z <destination IP> 3260
В KB 2020669 вы можете найти больше информации об этой команде.
4. Iperf
Эта утилита предназначена для контроля пропускной способности на интерфейсе. Она используется механизмом vSAN proactive network performance test, который доступен в интерфейсе vSAN. Поэтому при ее запуске вы получите сообщение "Operation not permitted". Чтобы она заработала, нужно создать ее копию:
По умолчанию утилита работает на портах, которые запрещены фаерволом ESXi, поэтому во время работы с ней нужно его потушить (не забудьте потом его включить):
esxcli network firewall set --enabled false
Теперь можно использовать эту утилиту для замера производительности канала (флаг -s - это сервер, -c - клиент):
Как вы знаете, в VMware vSphere 6.7 Update 1 средство обновления vSphere Update Manager (VUM) получило множество новых возможностей, в том числе функцию обновления микрокода (firmware) I/O-адаптеров серверов, входящих в состав кластера vSAN. Эта функциональность как раз перекочевала туда из интерфейса vSAN (называлось это раньше Configuration Assist).
VUM использует утилиту обновления драйверов от вендора оборудования (сервера). Таким образом, обновление драйвера I/O-устройства (HBA-адаптера) можно включить в двухступенчатый цикл обновления хоста и не заниматься этим отдельно, что уменьшает общее время обновления.
Если VUM не нашел утилиты обновления от вендора, он предлагает загрузить ее. Для этого он анализирует Release Catalog, учитывая информацию из HCL (Hardware Compatibility List). При этом поддерживаются и кастомные ISO-образы от OEM-производителей (версия билда ESXi также распознается).
Когда вы зайдете в Host Updates в VUM, вы увидите вот такое сообщение:
Firmware engine needs to download hardware vendor’s firmware tool to vCenter.
Если вы нажмете "Download vendor firmware tool", то увидите, что для загрузки утилиты обновления микрокода можно использовать как дефолтный, так и свой репозиторий:
Как это известно по ситуации с драйверами Windows, установщик не найдет нужный драйвер, поэтому, скорее всего, придется указать свой путь к утилите обновления, например для контроллера Dell PERC путь может выглядеть как-то так:
Обратите внимание, что по кнопке Browse можно указать свой файл, если у вас нет подключения к интернету:
Кстати, проверки состояния vSAN health checks интегрированы с рабочими процессами Update Manager, что позволяет приостановить процесс обновления хостов кластера в случае, если после обновление с одним из них пошло что-то не так. Также есть возможность загрузить на сервер vCenter файл HCL-манифеста в формате JSON, чтобы указать соответствия билдов ESXi и оборудования, если вы обновляетесь через VUM в офлайн-режиме.
Давно мы не писали о новостях сертификации VMware Certified Professionall (VCP), тем более, что с этого года несколько меняются принципы наименования и прохождения сертификации.
Для начала отметим, что по-прежнему для получения сертификации требуется прохождение курса (очно или онлайн) в одном из авторизованных центров (например - такого) и сдача двух экзаменов - VMware vSphere Foundations для соответствующей версии и специализированного экзамена для выбранного направления сертификации, например, VMware Certified Professional 6.5 – Data Center Virtualization.
С 16 января этого года VMware переходит от системы сертификаций по номеру версии продукта к системе с привязкой к году сертификации (то есть, если вы сдадите экзамен после 16 января, вы уже будете VCP 2019). Например:
Было: VMware Certified Professional – Desktop and Mobility 7 (VCP7-DTM)
Стало: VMware Certified Professional – Desktop and Mobility 2019 (VCP-DTM 2019)
Более подробно об этой системе для сертификаций VCP и VCAP написано здесь. Такая схема, во-первых, позволит работодателю или заказчику понять реальную актуальность сертификации (например, VCP6.5-DCV - полностью актуальная сертификация на данный момент, но сама платформа vSphere 6.5 вышла еще в 2016 году).
Второй момент - с 24 января будет доступен новый экзамен на базе VMware vSphere 6.7, что позволит получить актуальную сертификацию VCP 2019 для актуальной версии платформы.
Таким образом, вот так теперь выглядят планируемые сертификации VMware VCP для 2019 года:
Согласно политикам VMware, после выпуска новой версии экзамена старый объявляется устаревшим в течение 4 месяцев. Для тех, кто прошел сертификацию по прошлым версиям (не более двух версий назад), есть 3 варианта апгрейда:
Сдать новый экзамен.
Сдать дельта-экзамен (он поменьше) в рамах бридж-сертификации, если это допускает сертификация.
Использовать другие специфические опции VMware в рамках специальных анонсов.
Вот так выглядит путь апгрейда для VCP на данный момент:
А вот так - список бридж-путей для ресертификации от прошлых версий:
Недавно компания VMware сделала доступной онлайн интересную утилиту - VMware Configuration Maximums Tool. Она позволяет быстро и просто найти максимальные параметры конфигураций для различных продуктов VMware:
На данный момент поддерживаются решения NSX Data Center for vSphere, vSphere (правда пока еще нет vSphere 6.7 Update 1), VMware NSX-T, vRealize Operations Manager и VMware Site Recovery Manager, но, скорее всего, этот список будет быстро пополняться.
Помимо продукта VMware и его версии, можно также выбрать и категории максимумов, которые хочется посмотреть (хосты ESXi, виртуальные машины и т.п.). Также полученные результаты можно экспортировать в PDF.
Если в верхней части страницы перейти на вкладку Compare Limits, то мы увидим функционал сравнения максимумов в различных версиях продуктов. Например, выберем слева VMware vSphere 6.7 и сравним с ней две предыдущих версии платформы - vSphere 6.5 Update 1 и vSphere 6.5:
Результаты будут приведены в таблице (обратите внимание, что их можно экспортировать в CSV):
Недавно мы писали про то, как работает механизм регулирования полосы канала Network I/O Control (NIOC) в VMware vSphere, который позволяет приоритизировать различные типы трафика на одном сетевом адаптере, а сегодня взглянем на сам механизм прохождения трафика по уровням абстракции виртуального коммутатора изнутри.
Цепочка прохождения пакетов по сетевому стеку гипервизора ESXi через различные уровни называется Network IOChain. Это фреймворк, который позволяет на пути следования данных от виртуальной машины к физическому сетевому адаптеру производить различную модификацию данных и передачу их на следующий уровень.
IOChain обеспечивает связность виртуального коммутатора vSphere Standard Switch (VSS) или vSphere Distributed Switch (VDS) от групп портов на них к портам физических сетевым адаптеров (uplikns) в процессе передачи и обработки пакетов между этими сущностями. Для каждого из виртуальных коммутаторов есть 2 интерфейса IOChain (для входящего и исходящего трафика). Это дает большую гибкость по настройке политик каналов трафика Ingress и Egress.
Примерами таких политик служат поддержка сетей VLAN, механизма группировки NIC teaming и шейпинг трафика (traffic shaping). Работают эти политики на трех уровнях абстракции (в порядке следования от виртуальной машины):
Группа портов виртуального коммутатора (port group).
На этом уровне работает фильтрация VLAN, а также политики безопасности, такие как Promiscuous mode, MAC address changes и Forged transmits. Пользователи также могут настроить политики шейпинга исходящего трафика (для VSS) или в обоих направлениях (только для VDS).
Обычный или распределенный виртуальный коммутатор (VSS или VDS).
Основная задача этого уровня - направлять пакеты к нужному порту (аплинку), через которые они достигнут адреса назначения. Он оперирует MAC-адресами источника и назначения, а также определяет, отдавать ли трафик локально (в рамках одного или нескольких виртуальных коммутаторов на хосте), либо перенаправлять его к уровню аплинка хоста ESXi.
Кроме того, на этом уровне настраиваются правила NIC teaming по балансировке пакетов между аплинками, подключенными к данному коммутатору. Ну и на этом уровне можно также настраивать политики шейпинга и безопасности для всего виртуального коммутатора в целом.
Порт (uplink).
Этот уровень отвечает за передачу трафика к драйверу сетевого адаптера. На этом уровне работают функции hardware offloading, облегчающие работу с обработкой пакетов за счет ресурсов сетевой карты. Доступные возможности hardware offloading зависят от конкретной модели карты и ее драйвера. Примерами таких возможностей являются TCP Segment Offload (TSO), Large Receive Offload (LRO) и Checksum Offload (CSO). Также здесь обеспечивается поддержка оверлейных протоколов VXLAN и Geneve, которые используются в решениях NSX-v и NSX-T соответственно (эта поддержка есть во многих современных сетевых картах).
Помимо этого на уровне аплинка работают механизмы буфферизации пакетов при всплесках нагрузки (ring buffers), после чего пакеты передаются на DMA-контроллер, чтобы быть обработанными процессором карты и перенаправлены уже в сеть передачи данных.
Для обычного виртуального коммутатора (VSS) схема прохождения трафика через уровни абстракции IOChain
выглядит так:
Если же у вас распределенный виртуальный коммутатор VDS, то вы можете использовать механизм Network I/O Control (NIOC) для резервирования и приоритизации трафика внутри канала аплинков. Также VDS предоставляет множество дополнительных возможностей, таких как LBT (Load Balanced Teaming) и LACP (Link Aggregation Control Protocol).
В случае с VDS схема с IOChain выглядит следующим образом:
Обратите внимание, что на этой диаграмме есть дополнительный модуль DVfilter. Это API-фреймворк, который есть в VDS и требуется для работы решения NSX. Когда компоненты NSX устанавливаются в ядро ESXi, они взаимодействуют с трафиком именно через этот модуль.
С помощью команды summarize-dvfilter можно вывести все загруженные агенты DVfilter и фильтры. Вот так это выглядит без установленного решения NSX:
Если вы посмотрите информацию по компонентам NSX, когда он установлен, то увидите модули nxst-switch-security, nsxt-vsip и nsxt-vdrb.
Вообще, весь стек IOChain является модульным, что позволяет добавлять новую функциональность его компонентов на различных уровнях абстракции. Например, компоненты DVfilter разделяются на Fastpaths, Slowpaths и Filters:
Fastpaths – фильтры трафика на уровне ядра ESXi.
Slowpaths – интеграция со сторонними продуктами для сетевой инфраструктуры.
Filters – размещение фильтров в слоты для каждого из подходящих по модели сетевых адаптеров vNIC.
В VMware vSphere 6.7 в стеке IOChain появилось несколько улучшений, таких как поддержка MAC learning и функции IGMP snooping через интерфейс VNI (Virtual Network Interface), которые могут быть использованы в будущем.
Ну и напомним, что текущая версия распределенного виртуального коммутатора VDS - это 6.6, об их обновлении мы писали вот тут.
Весной 2018 года Selectel запустил услугу резервного копирования для Облака на базе VMware посредством Veeam® Backup&Replication™ (далее VBR). К реализации проекта мы подошли основательно, спланировали и выполнили следующий перечень работ:
Изучение документации и лучших практик по продуктам Veeam
Разработку архитектуры VBR уровня сервис-провайдера
Недавно мы писали о политиках хранилищ Storage Policy Based Management (SPBM) на базе тэгов, которые помогают использовать возможности платформы VMware vSphere для назначения виртуальным машинам хранилищ на томах VMFS/NFS с разными характеристиками, который работает на уровне отдельных виртуальных дисков.
Сегодня мы поговорим о политиках SPBM для виртуальных томов VVols на хранилищах, которые предоставляют различные возможности через интерфейс VASA (vSphere APIs for Storage Awareness). Механизм VASA реализуется производителем дисковой системы (storage provider) на программно-аппаратном уровне, при этом дисковый массив полностью отвечает за использование его возможностей, а со стороны vSphere возможно только управление ими средствами механизма SPBM.
Через интерфейс VASA Provider устройство хранения сообщает платформе vSphere, какие сервисы оно предоставляет, а через административный том на хранилище Protocol Endpoint (PE) происходит процессинг операций ESXi с массивом:
К таким возможностям в общем случае относятся:
Шифрование
Дедупликация данных на массиве
Репликация данных внутри массива и на другие массивы
Функции уровня обслуживания QoS (ограничения по IOPS и Latency)
Выбор яруса хранения / типа дисков (регулирование уровня производительности)
Также возможна реализация в массиве и других сервисов, таких как защита с помощью снапшотов, использование различных размеров блока для разных приложений и т.п.
Самое приятное в использовании механизма SPBM для хранилищ на основе VVols в том, что вам не требуется заботиться о томах LUN, дисковых группах и настройке их параметров - массив сам распорядится размещением данных по ярусам (Tiers) и датасторам, а также обеспечением уровня их производительности (Service levels).
Например, вот так просто выглядят правила (Rules) для первичного размещения виртуальных машин на массиве EMC Unity при выборе уровня обслуживания и производительности для новой политики SPBM:
В массивах может быть также реализован QoS в зависимости от критичности приложения (Mission Critical приложения всегда первыми получат ресурсы ввода-вывода):
Некоторые хранилища, например, HPE Nimble, могут предоставлять сразу большое число сервисов, для каждого из которых можно настроить свои правила:
Хранилище может предоставлять не только правила размещения виртуальных машин и обеспечения их функционирования, но и сервисы репликации, как например у Pure Storage (они позволяют, в том числе, настроить репликацию на уровне отдельных VMDK дисков машин):
Также создание политик SPBM для томов VVols можно посмотреть на видео ниже:
А вот так применяются политики SPBM, включая сервисы репликации:
Когда вы обновляете виртуальную инфраструктуру VMware vSphere, нужно также подумать и об обновлении виртуального коммутатора (vSphere Distributed Switch, VDS), который, в зависимости от версии, предоставляет те или иные возможности.
Если вы хотите обновить VMware vSphere 5.5 на последнуюю версию VMware vSphere 6.7 Update 1, то, как вы уже знаете, прямого апгрейда нет. Вам нужно будет обновиться на одну из версий - vSphere 6.0 или 6.5 - и потом уже накатить апгрейд до версии 6.7.
В этом процессе есть нюанс - если вы обновитесь с 5.5 на 6.x, то вам надо будет обновить и Distributed Switch, до того, как будете проводить апгрейд на версию 6.7. В противном случае процесс обновления до версии 6.7 завершится неудачно.
Обновить распределенный коммутатор очень просто: в vSphere Client нужно зайти в Networking, выбрать там ваш VDS-коммутатор и на вкладке "Summary" кликнуть на ссылку, где написано "Upgrades available":
Чтобы запустить процесс обновления VDS, нужно в меню "Actions" выбрать пункт "Upgrade":
В процессе обновления вам предложат выбрать версию VDS, если кликнуть на иконку <i>, то можно узнать какие фичи предоставляют соответствующие версии:
Обратите внимание, что соответствие версий VDS версиям vSphere следующее:
vSphere 6.0 = VDS 6.0
vSphere 6.5 = VDS 6.5
vSphere 6.7 = VDS 6.6 (да, вот так странно)
После обновления убедитесь, что виртуальный коммутатор имеет ту версию, которую вы выбрали:
И еще вам может оказаться полезной информация о потенциальных проблемах при обновлении на VDS 6.6, описанная в KB 52621.
Спустя всего 3 с небольшим месяца с момента анонса на конференции VMworld 2018 платформы для создания инфраструктуры виртуальных десктопов VMware Horizon 7.6, компания VMware выпустила обновление этого продукта - Horizon 7.7, включая обновленные клиенты Horizon Client 4.10.
Давайте посмотрим, что нового появилось в различных компонентах этого решения:
Улучшения совместимости и поддержка новых ОС
Поддержка Windows Server 2019 для серверов виртуальных десктопов и RDSH.
Пакет VMware Virtualization Pack for Skype for Business теперь может быть использован в окружении IPv6.
Клиенты Horizon Clients теперь включают поддержку последних операционных систем, таких как macOS 10.14 (Mojave) и Android 9.1.
Улучшения консоли Management Console
Новая Horizon Console (на базе HTML5) получила несколько улучшений:
Теперь можно добавлять пулы Manual и View Composer linked-clone, а также добавлять, отключать, изменять и удалять персистентные диски для связанных клонов.
На вкладке Machines можно быстро понять, когда кто-либо, кроме назначенного пользователя, заходил в виртуальную машину. Теперь есть 2 колонки: Connected User и Assigned User (фича также доступна в Horizon Administrator).
Старый Horizon Administrator в дэшборде System Health отображает детали о зарегистрированных модулях VMware Unified Access Gateway для версии 3.4 и более поздних:
Имя узла Connection Server pod теперь есть в верхней панели, рядом с заголовком:
Улучшение Help Desk Tool - администраторы теперь могут завершить процесс приложения для выбранного пользователя. База данных событий записывает это действие, включая такие детали, как дата и время, имя десктопа и название приложения, название пула и имя администратора.
Улучшения масштабируемости
Можно использовать один экземпляр vCenter Server для нескольких POD в архитектуре CPA (Cloud Pod Architecture).
Максимальное число серверов одной фермы RDSH было увеличено с 200 до 500.
Была введена поддержка vMotion для пулов linked-clone и automated, которые содержат также и полные виртуальные машины.
Поддержка vMotion была также добавлена для полных клонов с поддержкой vGPU, мгновенных клонов и связанных клонов.
Улучшения безопасности и надежности
Новая возможность аудита буфера обмена позволяет агентам Horizon Agent записывать информацию об активностях операций copy и paste между клиентом и агентом в журнал событий на машине агента.
Можно добавить устройство Virtual Trusted Platform Module (vTPM) к пулу десктопов instant-clone и удалить vTPM уже после операции по созданию образа.
Протокол TLS 1.0 теперь отключен по умолчанию на всех клиентах.
Улучшения User Experience
Улучшения протокола Blast Extreme:
Теперь можно использовать протокол Blast Extreme для доступа к физическим компьютерам и рабочим станциям.
Для Windows-клиентов протокол кодирования видео Blast Extreme HEVC (H.265) позволяет ужимать почти в два раза эффективнее чем раньше (при том же качестве), либо улучшать качество на той же самой полосе, как и H.264. Также добавлена поддержка режима 8K. Это требует окружения NVIDIA GRID с аппаратными кодировщиками NVIDIA и клиентов, железо которых поддерживает декодирование HEVC.
Улучшения Windows-клиентов:
Если включена возможность client-drive redirection, пользователи могут перетаскивать файлы и папки между клиентской системой и удаленными десктопами или опубликованными приложениями. Например, можно перетащить несколько графических файлов в опубликованное приложение (например, закинуть аттач в почтовый клиент).
Новая возможность VMware Virtual Print позволяет пользователю печатать на любом Windows-компьютере (она делает то же самое, что и ThinPrint ранее). Но, помимо этого, VMware Virtual Print поддерживает перенаправление принтеров клиента, а также location-based printing. Настройки сохраняются на уровне пользователей.
Улучшение опубликованных приложений и десктопов RDSH:
Режим multi-session mode, который позволяет администратору задать правило - можно ли пользователю открывать несколько сессий к одному приложению с различных устройств. Требует Horizon Client 4.10.
На Windows-клиентах пользователю можно назначить приложение RDSH для отображения на одном мониторе или на наборе из нескольких экранов.
Новая возможность hybrid logon может быть использована с функцией доступа для неавторизованных пользователей. Она позволяет неаутентифицированным пользователям, но с доступом к домену, получить доступ к сетевым ресурсам (файловые шары, принтеры), без ввода данных учетной записи домена. Требует Horizon Client 4.10.
Улучшения работы публичного облака VMware Cloud on AWS (SDDC версии 1.5)
Минимально требуемый размер кластера vSphere был уменьшен до 3 узлов. Также поддерживаются "растянутые" кластеры (stretched clusters).
Поддержка технологий VMware NSX-T network virtualization и VMware vSAN datastore encryption.
Поддержка технологий Horizon 7 издания Enterprise Edition: VMware User Environment Manager, VMware App Volumes и техники VMware Instant Clone.
Улучшения и новые возможности VMware Horizon 7 for Linux
Десктопы Linux теперь поддерживаются в инфраструктуре Horizon 7 on VMware Cloud on AWS.
Режим Single sign-on (SSO) теперь поддерживается для десктопов SLED/SLES 12.x.
Аудиовход теперь поддерживается для десктопов SLED/SLES.
Плавающий пул десктопов Instant clone теперь доступен при использовании SLED/SLES .
Функция session collaboration доступна при использовании Linux-десктопа. Теперь можно приглашать других пользователей присоединиться к удаленной сессии.
Десктопы Instant clone на базе Linux теперь позволяют офлайновое присоединение к домену Active Directory через Samba.
Более подробная информация о VMware Horizon 7.7 приведена по этой ссылке. Также здесь можно почитать документацию о VMware Horizon Clients, а вот тут написано про новые возможности Unified Access Gateway 3.4.
Компоненты VMware Horizon 7.7 доступны для загрузки уже сейчас по этой ссылке.
Недавно компания Gartner выпустила Magic Quadrant for Hyperconverged Infrastructure (HCI) за 2018 год, посвященный средствам создания гиперконвергентной инфраструктуры. Это такая среда, которая позволяет объединить вычислительные ресурсы, системы хранения и сети с помощью технологий виртуализации и собрать все компоненты в единую интегрированную сущность, которая управляется из одной точки.
Напомним, что об этом квадранте мы уже писали в начале года, и с тех пор кое-что изменилось:
Вот как было в январе этого года:
Главным лидером рейтинга, как и прежде, сейчас признана компания Nutainx - производитель продуктов для создания гиперконвергентной среды. Сейчас Nutanix поставляет как чисто программные решения (в виде виртуальных модулей), так и программно-аппаратные комплексы (партнерские решения Lenovo, Dell EMC, Fujitsu и IBM). Помимо этого, Nutanix в рамках раннего доступа запустила и облачный сервис для своих HCI-решений.
Несмотря на то, что VMware - это производитель только программных решений, она попала в сегмент лидеров вполне заслуженно. У VMware в последние годы было выпущено очень много того, что относится к HCI - например, сейчас компания поддерживает более 500 моделей серверов в рамках программы ReadyNode для построения кластеров vSAN.
Также VMware поддерживает инициативу VMware Cloud Foundation (VCF), о которой мы много писали в последнее время. Архитектура VCF включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия, которые желательно развертывать все вместе, но можно какие-то и опустить.
Ну и, конечно же, в последнее время VMware делает очень много усилий по продвижению гибридной среды VMware Cloud on AWS, которая будет доступна не только из облака, но и в частной инфраструктуре предприятий (Amazon Outposts).
Родительская компания VMware - Dell EMC - в этом квадранте занимает высокое место благодаря решениям VxRail и VxRack, в состав которых, кстати, входит продукт для создания кластеров отказоустойчивых хранилищ vSAN.
Обратите внимание, что существенный прогресс наблюдается у Cisco - из сегмента челенджеров она переместилась в лидеры. Прежде всего, это случилось благодаря доработке платформы Cisco HyperFlex, котора интегрирует в себе архитектуру Cisco Unified Computing System (UCS), сочетающую в себе продукты Network Fabric, управляющую облачную консоль Intersight, сторонний гипервизор (например, ESXi), а также платформу для управления хранилищами и данными HX Data Platform (разработанную компанией Springpath, которую Cisco купила в сентябре 2017 года).
О магических квадрантах Gartner
Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:
полнота видения (completeness of vision)
способность реализации (ability to execute)
Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:
Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.
В начале года мы рассказывали о книге Upgrading to VMware vSphere 6.5, которая описывала процедуры апгрейда платформы виртуализации на версию 6.5. С тех пор были выпущены обновления vSphere 6.7 и 6.7 Update 1, поэтому документ потерял актуальность.
В связи с этим VMware выпустила обновленную книгу Дэвида Стамена (David Stamen) Upgrading to VMware vSphere 6.7, которая стала доступна для скачивания на днях:
В обновленную версию также включены все нововведения последних версий продуктов Site Recovery Manager и Horizon, которые работают в инфраструктуре vSphere. С точки зрения основной платформы, рассматриваются сценарии апгрейда с vSphere 6.0 и 6.5.
В книге процесс обновления разбит на три фазы:
Фаза 1: Pre-upgrade – обозначает фронт работ и требований, которые должны быть выполнены перед началом процедуры апгрейда.
Фаза 2: Upgrade – описание шагов процесса обновления и иллюстрация их исполнения.
Фаза 3: Post-Upgrade – валидация результата в соответствии с изначально поставленными целями.
Скачать книгу Upgrading to VMware vSphere 6.7 можно по этой ссылке.
Как знают многие пользователи решения для создания отказоустойчивых кластеров VMware vSAN, в данном продукте есть возможность перевода хоста в режим обслуживания (Enter Maintenance Mode, EMM), который позволяет вывести его на время из эксплуатации с сохранением работоспособности кластера в целом. При этом происходит взаимодействие vSAN и механизма балансировки нагрузки VMware vSphere Distributed Resource Scheduler (DRS), который эвакуирует виртуальные машины с хоста ESXi.
Давайте посмотрим, как работает EMM для кластера vSAN, и какие есть опции для данной процедуры. Чтобы перевести хост ESXi в режим обслуживания, надо нажать на него правой кнопкой в vSphere Client и выбрать пункт Maintenance Mode > Enter Maintenance Mode.
Далее мы увидим окно перевода хоста в режим обслуживания, где можно выбрать одну из трех опций:
Full Data Migration – это миграция всех компонентов дисковых объектов на другие хосты кластера.
Ensure Accessibility – это миграция только тех компонентов, которые есть в кластере в единственном экземпляре. При этом, для некоторых объектов в этом случае не будет соблюдена политика Failures to tolerate (FTT).
No Data Migration – в этом случае никакие компоненты не будут перемещены с хоста, поэтому некоторые ВМ могут оказаться недоступными (если на этом хосте их дисковые компоненты находятся в единственном экземпляре, а уровень RAID недостаточен для предоставления доступа к объекту).
С первым пунктом (Full Data Migration) все ясно - он вызывает долговременную процедуру миграции всех дисковых объектов и не всегда оправдан, когда хост ESXi нужно погасить лишь ненадолго. Но если вы выводите хост ESXi из эксплуатации производственного кластера (либо останавливаете, например, на несколько дней), то нужно выбирать именно Full Data Migration.
Давайте подробнее рассмотрим вариант Ensure Accessibility, который как раз подходит для кратковременного обслуживания хоста и последующего его повторного ввода в эксплуатацию. Если у вас достаточно запаса дисковых ресурсов, и виртуальные диски машин работают в RAID-1, то копии дисковых объектов переводимого в режим обслуживания хоста должны быть на других серверах. На картинке ниже реплика объекта C1 есть на другом хосте, поэтому в режиме Ensure Accessibility никаких миграций данных производиться не будет, кластер продолжит работать в режиме полной производительности:
Если же у вас, например, задана политика кластера FTT=1 на четырех хостах, и компоненты дисковых объектов хранятся в соответствии с политикой RAID-5, то картина будет следующей:
В этом случае EMM также не будет перемещать никаких компонентов, так как данные дискового объекта в целом продолжают оставаться доступными. Более подробно о различных вариантах перехода в режим EMM вы можете почитать вот в этой статье.
Между тем, если vSAN object manager будет наблюдать ситуацию несоответствия политики надежности более чем 60 минут (см. параметр Object repair timer в конце статьи), то он, все-таки, запустит синхронизацию дисковых объектов, чтобы их конфигурация в итоге соответствовала действующим политикам.
Кстати, обратите внимание, что такое поведение кластера vSAN - это одна из причин, почему VMware Update Manager не делает обновление хостов ESXi кластера vSAN в параллельном режиме, а проводит это последовательно. Ведь если бы это происходило параллельно, не факт, что можно было бы выполнить требования опции Ensure Accessibility, а также происходило бы много миграций дисковых компонентов.
Кроме того, перед переходом в режим обслуживания хоста, EMM делает полную симуляцию перемещений данных, которые будут проведены в процессе выключения хоста. Например, у нас есть 3 виртуальные машины: vm01 с политикой RAID-0 (без избыточных копий данных), а также машины vm02 и vm03 в режиме RAID-1 (зеркало).
Обратите внимание на картинку ниже:
Здесь показано, что в соответствии с вариантом No data migration 3 дисковых объекта виртуальной машины vm01 окажутся недоступными, а 30, относящихся к vm02 и vm03, не будут соответствовать действующей политике по обеспечению надежности.
Если мы нажмем на ссылку See detailed report, то увидим подробную картину симуляции EMM:
То есть, vm01 окажется недоступной, а vm02 и vm03 будут Non-compliant, пока хост находится в режиме обслуживания.
Если же вы выберете вариант Ensure Accessibility, то прогноз будет следующим:
440 МБ дисковых объектов, относящихся к vm01 будут перемещены, а 30 объектов не будут соответствовать политике, при этом все ВМ останутся доступными. Также в VMware vSAN 6.7 Update 1 появились новые предупреждения о том, что в кластере есть активные процессы синхронизации, а также переходящие или уже перешедшие в режим обслуживания хосты ESXi.
Ну и напомним о настройке Object Repair Timer, которую мы детально рассматривали вот тут. Она то, как раз, и позволяет вам расширить окно обслуживания хоста ESXi в Maintenance Mode, если вам это требуется для проведения какой-то долгой операции. По умолчанию синхронизация не соответствующих политике дисковых объектов начнется через 60 минут:
Удобно, что эта настройка задается на уровне всего кластера vSAN, поэтому не нужно как раньше ходить на каждый хост ESXi и задавать ее.
Как многие из вас знают, в последней версии платформы виртуализации VMware vSphere 6.7 Update 1 компания VMware сделала поддержку горячей миграции vMotion для виртуальных машин, которые имеют на борту технологию vGPU в целях прямого использования ресурсов видеокарт NVIDIA.
Напомним, что ранее была введена поддержка операций Suspend/Resume для GRID, а теперь появилась и поддержка горячей миграции vMotion для машин с привязкой к карточкам NVIDIA Quadro vDWS.
Между тем, по умолчанию эта поддержка для виртуальных машин отключена, и чтобы начать пользоваться этой функцией нужно внести изменения в настройки vCenter. Если вы попробуете сделать vMotion машины с vGPU, то получите вот такую ошибку:
Migration was temporarily disabled due to another migration activity. vGPU hot migration is not enabled.
Вильям Лам написал о том, как включить поддержку vMotion в этой ситуации. Вам надо пойти в Advanced Settings на сервере vCenter и поставить там значение true на настройки vgpu.hotmigrate.enabled:
Эта настройка также рассматривается в документации вот тут. Надо отметить, что вступает в действие она сразу же, и вы можете делать не только vMotion, но и Storage vMotion любой машины (одновременно с vMotion, кстати). Помните, что для успешной работы vMotion на всех хостах ESXi должны быть карточки NVIDIA GRID и установлен соответствующий VIB-пакет.
Также установить эту настройку можно и с помощью командлета PowerCLI:
Компания Amazon, в рамках конференции AWS re:Invent 2018, объявила о запуске инициативы AWS Outposts, которая будет предоставлять облачные сервисы AWS на площадке и оборудовании заказчика, в том числе сервисы VMware Cloud on AWS.
По-сути, механизм AWS Outposts позволит вам использовать стандартные сервисы AWS, как будто они работают в облаке, но реально исполнять их на своем оборудовании. Это позволит получить все сервисы AWS SDDC, такие как vSphere, NSX и vSAN в своем датацентре, при этом платить по модели повременного использования ресурсов AWS.
Такое может пригодиться в отраслях, где существуют высокие требования к задержкам проведения операций (latency), что требует локального исполнения вычислительных ресурсов, например, в телекоме, высокочастотной биржевой торговле, промышленной автоматизации, финансовых сервисах, ИТ-системах здравоохранения и других приложениях.
Здесь логично напрашивается вопрос - а зачем нужно локально исполнять VMware Cloud on AWS, если можно просто развернуть на своем оборудовании VMware vSphere и остальные компоненты? Использовать VMware Cloud on AWS в таком режиме будет целесообразно, когда у вас есть гибридная среда из локальных и облачных датацентров, а вы хотите получать виртуальные ресурсы от единого поставщика - Amazon, а сервисы по управлению и апдейту всех компонентов SDDC - от VMware.
Также можно будет использовать единую консоль VMConAWS для управления всеми виртуальными инфраструктурами в распределенных датацентрах с возможностью соблюдения единых требований к оборудованию и ПО, политик и рабочих процессов.
Надо отметить, что AWS Outposts предполагает развертывание как в варианте с VMware Cloud on AWS, так и без него - с нативными службами Amazon и их API.
Сервис AWS Outposts будет доступен для пользователей, начиная со второй половины 2019 года. Изменения можно отслеживать на этой странице.
Возможность создания внешнего PSC появилась в версии vSphere 6.0, а еще в vSphere 5.1 компания VMware предоставила возможность размещать отдельные компоненты, такие как VMware Update Manager (VUM) или vCenter Server Database (VCDB) на отдельных серверах. Это привело к тому, что средства управления виртуальной инфраструктурой можно было развернуть аж на 6 серверах, что рождало проблемы интеграции, обновления и сложности обслуживания.
Когда VMware предложила модель с внешним PSC инфраструктура свелась всего к двум узлам сервисов vCenter. PSC обслуживает инфраструктуру SSO (Single Sign-On), а также службы лицензирования, тэгов и категорий, глобальных прав доступа и кастомных ролей. Помимо этого PSC отвечает за сертификаты данного SSO-домена.
В то время, как службы PSC принесли гибкость развертывания, они же принесли и сложность обслуживания, так как для них нужно было обеспечивать отдельную от vCenter процедуру отказоустойчивости в инфраструктуре распределенных компонентов vCenter Enhanced Linked Mode (ELM).
Еще в vSphere 6.7 и vSphere 6.5 Update 2 была введена поддержка режима ELM для Embedded PSC, поэтому с внедренным PSC уже не требуется обеспечивать отказоустойчивость дополнительных узлов, балансировку нагрузки, а также их обновление. Теперь можно обеспечивать доступность узлов vCenter посредством технологии vCenter High Availability.
Поэтому уже сейчас можете использовать vCenter Server Converge Tool для миграции внешних PSC на Embedded PSC виртуального модуля vCenter Server Appliance. А возможности развернуть внешние PSC в следующих версиях vSphere уже не будет.
Таги: VMware, vSphere, HA, vCenter, PSC, Update, vCSA
Многие администраторы VMware vSphere весьма консервативны и подолгу не обновляют версию платформы виртуализации, даже когда есть деньги на продление поддержки. Отчасти это верная стратегия - VMware так часто пропускает серьезные баги в мажорных релизах, что многие ждут пока обновление "настоится".
Но долго ждать тоже не стоит, так как можно недополучить преимущества новых версий. Например, всегда от релиза к релизу у платформы vSphere растет производительность в различных аспектах. В частности, давайте посмотрим, как выросла производительность технологии миграции хранилищ Storage DRS в VMware vSphere 6.7 по сравнению с версией 6.5.
VMware провела тестирование двух версий платформы и посмотрела, как быстро происходит генерация рекомендаций DRS в разрезе следующих операций в кластере:
CreateVM
CloneVM
ReconfigureVM (добавление дополнительного диска)
RelocateVM (перемещение на другой датастор)
Datastore Enter Maintenance (перевод датастора в режим обслуживания)
При одновременном исполнении в кластере множества данных задач одновременно имеет значение своевременное формирование рекомендаций (куда поместить ВМ, куда ее клонировать и т.п.). По итогам тестирования были получены следующие результаты (столбики показывают процент улучшения по времени для 5 одновременных исполняемых операций):
Для 16 одновременных операций:
Отдельно представлен график для операций Datastore Enter Maintenance:
Все это приводит к увеличению скорости развертывания и миграции виртуальных машин и их VMDK-дисков в больших инфраструктурах, где в этом участвует механизм SDRS (генерация рекомендаций по размещению виртуальных машин).
Уважаемые читатели! Некоторые из вас знают, что у нас на сайте есть цикл статей от Романа Гельмана, который разрабатывает различные функции своего PowerCLI-модуля Vi-Module. Они позволяют управлять многими аспектами виртуальной инфраструктуры VMware vSphere с помощью механизмов, недоступных в рамках стандартных средств управления.
Недавно Роман подал свой англоязычный блог ps1code.com на голосование по выбору лучшего блога о виртуализации Top vBlog 2018. И мы от лица всей редакции очень просим проголосовать за Романа - ведь его блог этого действительно достоин!
Спасибо вам заранее.
И вот статьи Романа на нашем ресурсе, чтобы вам удобнее было найти нужную функцию:
Некоторое время назад мы рассказывали об анонсах конференции VMworld Europe 2018, одним из которых была покупка компании Heptio, предоставляющая решения для управления контейнерами платформы Kubernetes в облаке. Ну а на днях на сайте проекта VMware Labs появился плагин к vSphere Client, который позволяет видеть кластеры и узлы Kubernetes, которые находятся под управлением Pivotal Container Service - vSphere PKS Plugin.
Возможности плагина PKS:
Визуализация, настройка и управление кластерами Kubernetes, развернутыми и управлеяемыми с помощью PKS.
Средства просмотра нижележащей инфраструктуры для контейнеров, включая виртуальные машины, сетевые ресурсы и объекты хранилищ, которые созданы в кластере Kubernetes, развернутом в окружении VMware vSphere.
Единая точка просмотра компонентов кластера Kubernetes, включая узлы и сетевые объекты, такие как роутеры, логические коммутаторы и балансировщики.
Простой интерфейс для доступа к кластеру через kubectl и дэшборд.
Для работы плагина вам понадобятся следующие компоненты:
PKS v1.2.x
NSX-T v2.3
vSphere v6.7.x, v6.5 U1, U2
Загрузить vSphere PKS Plugin можно по этой ссылке (там же вы найдете и документацию).
Совсем недавно стало известно о трех очень серьезных багах в платформе VMware vSphere, которые затронули, как платформу vSphere 5.x/6.x, так и средство создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 6.6/6.7.
1. Повреждение данных виртуальных дисков снапшотов формата SEsparse.
Начиная с VMware ESXi 5.5, диски стапшотов виртуальных машин стали создаваться в формате SEsparse. Такой диск создается в ESXi 5.5 если диск машины более 2 ТБ, а начиная с ESXi 6.0 / VMFS6 - он используется для снапшотов всех машин. Так что под угрозой практически все виртуальные машины со снапшотами. А ведь снапшоты используются всеми ВМ, для которых применяется резервное копирование через механизм vSphere API for Data Protection (например, с помощью продукта Veeam Backup and Replication).
Ну а суть бага заключается в том, что блоки данных могут оказаться поврежденными, что приводит к неконсистентности файлов для приложений (например, баз данных), а также иногда к невозможности загрузки виртуальной машины!
Баг и возможные способы решения описаны в KB 59216. В vSphere 6.7 Update 1 баг уже пофикшен. Для остального есть следующие апдейты:
Для ESXi 5.5 обновления нет, но вы можете отключить функцию "IO coalescing" для формата дисков SEsparse. Делается это следующей командой:
esxcli system settings advanced set -i 0 -o /COW/COWEnableIOCoalescing
2. Проблема консистентности виртуальных дисков машин на платформе vSAN 6.6.
Аналогично багу из прошлого пункта, здесь может произойти неприятность с целостностью данных виртуальных машин, которые работают в кластере хранилищ VMware vSAN 6.6. Это может случиться в следующих обстоятельствах:
vSAN начинает процесс ресинхронизации
В этот момент вы расширяете диск VMDK виртуальной машины
vSAN снова начинает ресинхронизировать уже расширенный диск виртуальной машины
Проблема описана в KB 58715. В этом случае вы сможете только восстановить консистентность виртуальных машин, но сами данные приложений вы уже не вернете.
3. Получение доступа root к хосту ESXi из виртуальной машины.
Если вы используете виртуальные машины с драйвером сетевого адаптера vmxnet3 (у него был еще один отдельный баг), то для непропатченных хостов есть возможность получения доступа root к шеллу ESXi из виртуальной машины.
Кстати, это было публично показано впервые:
#GeekPwn2018 Chaitin Tech security researcher f1yyy has escaped VMware EXSi and got root shell on the host for the first time in the world. After demonstrating it at GeekPwn 2018, f1yyy received the Best of Tech Award and was selected to the GeekPwn Hall of Fame.@GeekPwnpic.twitter.com/2Y2kYKaw4d
Информация об этой уязвимости опубликована в VMware advisory VMSA-2018-0027. Там же есть и названия необходимых вам патчей (обратите внимание, что багу подвержены также и платформы Workstation / Fusion).
Мы много писали о рещениях NVIDIA GRID / Quadro vDWS (они используют технологии virtual GPU или vGPU), например здесь, здесь и здесь. Ранее эта технология предполагала только применение vGPU для нагрузок в виртуальных машинах, которые требовательны к графике, поэтому используют ресурсы графического адаптера в разделенном режиме.
Между тем, начиная с недавнего времени (а именно с выпуска архитектуры Pascal GPU), VMware и NVIDIA предлагают использование vGPU для задач машинного обучения (CUDA / Machine Learning / Deep Learning), которые в последнее время становятся все более актуальными, особенно для крупных компаний. С помощью этой технологии виртуальная машина с vGPU на борту может эффективно использовать библиотеки TensorFlow, Keras, Caffe, Theano, Torch и прочие.
Например, можно создать использовать профиль P40-1q vGPU для архитектуры Pascal P40 GPU, что позволит иметь до 24 виртуальных машин на одном физическом адаптере (поскольку на устройстве 24 ГБ видеопамяти).
Зачем же использовать vGPU для ML/DL-задач, ведь при исполнении тяжелой нагрузки (например, тренировка сложной нейронной сети) загружается все устройство? Дело в том, что пользователи не используют на своих машинах 100% времени на исполнение ML/DL-задач. Большинство времени они собирают данные и подготавливают их, а после исполнения задачи интерпретируют результаты и составляют отчеты. Соответственно, лишь часть времени идет большая нагрузка на GPU от одного или нескольких пользователей. В этом случае использование vGPU дает максимальный эффект.
Например, у нас есть 3 виртуальных машины, при этом тяжелая нагрузка у VM1 и VM2 пересекается только 25% времени. Нагрузка VM3 не пересекается с VM1 и VM2 во времени:
Компания VMware проводила тест для такого случая, используя виртуальные машины CentOS с профилями P40-1q vGPU, которые имели 12 vCPU, 60 ГБ памяти и 96 ГБ диска. Там запускались задачи обучения TensorFlow, включая комплексное моделирование для рекуррентной нейронной сети (recurrent neural network, RNN), а также задача распознавания рукописного текста с помощью сверточной нейронной сети (convolution neural network, CNN). Эксперимент проводился на серверах Dell PowerEdge R740 с 18-ядерным процессором Intel Xeon Gold 6140 и карточками NVIDIA Pascal P40 GPU.
Результаты для первого теста оказались таковы:
Время обучения из-за наложения окон нагрузки в среднем увеличилось на 16-23%, что в целом приемлемо для пользователей, разделяющих ресурсы на одном сервере. Для второго теста было получено что-то подобное:
Интересен тест, когда все нагрузки исполнялись в одном временном окне по следующей схеме:
Несмотря на то, что число загруженных ML/DL-нагрузкой виртуальных машин увеличилось до 24, время тренировки нейронной сети увеличилось лишь в 17 раз, то есть даже в случае полного наложения временных окон рабочих нагрузок есть некоторый позитивный эффект:
Интересны также результаты с изменением политики использования vGPU. Некоторые знают, что у планировщика vGPU есть три режима работы:
Best Effort (это исполнение задач на вычислительных ядрах по алгоритму round-robin).
Equal Share (всем дается одинаковое количество времени GPU - это позволяет избежать влияния тяжелых нагрузок на легкие машины, например).
Fixed Share (планировщик дает фиксированное время GPU на основе профиля нагрузки vGPU).
VMware поэкспериментировала с настройками Best Effort и Equal Share для тех же тестов, и вот что получилось:
С точки зрения времени исполнения задач, настройка Best Effort оказалась лучшим выбором, а вот с точки зрения использования GPU - Equal Sharing меньше грузила графический процессор:
Мы немного рассказывали о новой функции технологии VMware HA, которая появилась в vSphere 6.5 - Orchestrated Restart (она же VM Restart Dependency). С помощью нее можно сделать так, чтобы виртуальные машины (или группы ВМ) могли запускаться после того, как предварительно будет запущена указанная ВМ или группа.
На практике это работает так. В vSphere Web Client идем на вкладку Configure для выбранного кластера HA и в разделе VM/Host Groups добавляем группу ВМ:
Далее в группу добавлем одну или несколько виртуальных машин:
Например, мы создали 3 группы (в данном случае, это классическая трехзвенная архитектура - серверы БД, серверы приложений и веб-серверы):
После этого можно задать правила запуска групп виртуальных машин в разделе VM/Host Rules, указав предварительное условие для запуска некоторой группы:
В данном случае мы запускаем серверы приложений только после запуска серверов баз данных. Очевидно, что нужно создать такое же правило для веб-серверов, которые будут запускаться после серверов приложений. Это и создаст требуемые зависимости ВМ для их запуска в случае сбоя одного или нескольких хостов в кластере VMware HA. Это и называется VMware HA Orchestrated Restart.
В то же время, у виртуальных машин в кластере HA есть параметр VM Restart Priority, который определяет приоритет запуска виртуальных машин в случае их восстановления после сбоя:
Этот вопрос затрагивает Дункан в своей заметке о настройке VM dependency restart condition timeout. Оказывается, она задает задержку между стартом виртуальных машин разного приоритета (а не для групп зависимостей, как может показаться из названия) и по умолчанию выставлена в 600 секунд.
Так вот, возвращаясь к Restart Priority и VM Dependency, Вова в комментариях к статье об HA Orchestrated Restart спросил: а что важнее - приоритет или зависимости? Опираясь на слова Дункана ("Restart Dependency is a rule, a hard rule, a must rule, which means there’s no time-out. We wait until all VMs are restarted when you use restart dependency"), можно сказать, что зависимости важнее - сначала будут подняты все машины первичной группы (между которыми будет соблюдаться порядок запуска в рамках приоритета), а потом уже те, которые от них зависят.
Таким образом, ответ на вопрос Вовы ("Допустим ВМ1 имеет приоритет high, но зависит от ВМ2 которая имеет приоритет low. Какая будет последовательность запуска?") - сначала запустится ВМ2.
RSS
